Introduce a new module encrypt, with the two structs Encrypter and Decrypter, pretty similar to Signer and Verifier. With the introduction of EVP_PKEY_CTX_set_rsa_oaep_md in openssl-sys, this new abstraction allows to perform RSA OAEP encryption and decryption without directly relying of unsafe calls.

As already discussed with @sfackler, there is a pretty good amount of code duplication, there is a good opportunity to use traits to abstract away sign and encrypt algorithms (i.e. OAEP can only be used for encryption, PSS only for signing). This PR could be a good starting point to analyze the current situation and, maybe, to understand how in the future the abstractions could be improved.

I would like some feedback, mostly because I could have missed some potential problem. Let me know what you think and just tell me what's missing.

Closes #1383

EDIT: I forgot to mention: I copied the API from Signer/Verifier, but I think that having to preallocate a buffer without knowing the exact size needed is pretty inconvenient. IMHO two versions of encrypt and decrypt should be provided, one that returns a Vec<u8>, the other that takes a buffer. I would like to hear your opinion about naming, because if I follow something like encrypt(in: &[u8]) -> Vec<u8> and encrypt_buf(in: &[u8], out: &mut [u8]) (which would be my approach), I will immediately break the API convention of Signer/Verifier. Moreover, I also think that taking a &mut Vec<u8> could be convenient, to allow automatic buffer resizing, but on the other hand some questions would rise: the vec should be automatically cleared if non-empty? Or it should follow the same principles of Read::read_to_end and similar?

P.S.: there is an issue about invalid C compiler parameters, which breaks the CI because -Werror is enabled, you probably already know that.

TODO

• Module documentation